Frontend Content Security Policy: Geavanceerde XSS-bescherming

In de hedendaagse verbonden wereld is de beveiliging van webapplicaties van het grootste belang. Cross-Site Scripting (XSS)-aanvallen blijven een aanhoudende bedreiging, waardoor aanvallers kwaadaardige scripts kunnen injecteren in websites die door andere gebruikers worden bekeken. Een van de meest effectieve wapens in uw arsenaal tegen XSS is de Content Security Policy (CSP). Deze gids duikt diep in geavanceerde CSP-technieken om robuuste bescherming te bieden voor uw frontend-applicaties, en zo een veiligere browse-ervaring voor gebruikers wereldwijd te garanderen.

Wat is de Content Security Policy (CSP)?

De Content Security Policy (CSP) is een HTTP-responseheader waarmee u kunt bepalen welke bronnen een webpagina mag laden. Door een CSP te definiëren, vertelt u de browser welke origins (domeinen, protocollen en poorten) als veilige bronnen worden beschouwd voor content, zoals scripts, stylesheets, afbeeldingen en lettertypen. Wanneer de browser een bron tegenkomt die de CSP schendt, blokkeert hij de bron, waardoor het risico op XSS en andere code-injectieaanvallen wordt verkleind.

Belangrijke CSP-richtlijnen

CSP werkt via een reeks richtlijnen, die elk een ander aspect van het laden van bronnen beheren. Het begrijpen van deze richtlijnen is cruciaal voor het implementeren van een effectieve CSP. Hier zijn enkele van de belangrijkste:

• default-src: Dit is de fallback-richtlijn voor alle brontypes die geen specifieke richtlijn hebben toegewezen. Het is over het algemeen een goede gewoonte om dit op 'none' in te stellen om alles standaard te blokkeren en vervolgens specifieke bronnen expliciet toe te staan.
• script-src: Deze richtlijn bepaalt de bronnen van waaruit JavaScript kan worden uitgevoerd. Dit is misschien wel de belangrijkste richtlijn voor het voorkomen van XSS-aanvallen.
• style-src: Deze richtlijn bepaalt de bronnen van waaruit stylesheets (CSS) kunnen worden geladen.
• img-src: Deze richtlijn bepaalt de bronnen van waaruit afbeeldingen kunnen worden geladen.
• font-src: Deze richtlijn bepaalt de bronnen van waaruit lettertypen kunnen worden geladen.
• connect-src: Deze richtlijn bepaalt de bestemmingen waarnaar de webpagina netwerkverzoeken kan doen (bijv. AJAX-calls, WebSockets).
• media-src: Deze richtlijn bepaalt de bronnen van waaruit media (audio en video) kunnen worden geladen.
• object-src: Deze richtlijn bepaalt de bronnen van waaruit plug-ins (bijv. Flash) kunnen worden geladen.
• frame-src / child-src: (child-src heeft de voorkeur) Deze richtlijnen bepalen de bronnen van waaruit frames (<iframe>) kunnen worden geladen. frame-src is verouderd ten gunste van child-src.
• form-action: Deze richtlijn bepaalt de URL's waarnaar formulierinzendingen zijn toegestaan.

Veelvoorkomende CSP-waarden

Binnen elke richtlijn specificeert u toegestane bronnen met behulp van verschillende waarden:

• 'none': Blokkeert alle bronnen van dat type. Dit is vaak het startpunt voor een veilige CSP.
• 'self': Staat bronnen van dezelfde origin (schema, domein en poort) als de pagina toe.
• 'unsafe-inline': Staat inline JavaScript (bijv. event handlers zoals onclick) en inline CSS toe. Dit wordt over het algemeen afgeraden vanwege de veiligheidsrisico's.
• 'unsafe-eval': Staat het gebruik van onveilige JavaScript-functies zoals eval(), new Function() en setTimeout() met een string-argument toe. Dit wordt sterk afgeraden.
• data:: Staat het laden van bronnen uit data-URI's toe (bijv. afbeeldingen die rechtstreeks in HTML zijn ingesloten).
• *: Staat alle bronnen toe. Gebruik dit spaarzaam, of helemaal niet, omdat het de effectiviteit van CSP ernstig beperkt.
• URL's (bijv. https://example.com, https://*.example.com): Staat bronnen van gespecificeerde URL's toe. Wildcards (*) kunnen worden gebruikt voor subdomeinen.
• nonce-value: Staat inline scripts of stijlen met een specifiek nonce-attribuut toe. Dit is de aanbevolen aanpak voor het toestaan van inline JavaScript wanneer dit absoluut noodzakelijk is. (Zie de sectie 'Nonces en Hashes').
• sha256-hashvalue, sha384-hashvalue, sha512-hashvalue: Staat inline scripts of stijlen toe waarvan de inhoud overeenkomt met een specifieke cryptografische hash. (Zie de sectie 'Nonces en Hashes').

Een robuuste CSP implementeren

Het implementeren van een sterke CSP vereist een zorgvuldige planning en uitvoering. Hier is een stapsgewijze handleiding:

1. Beoordeling en planning

Voordat u begint, moet u begrijpen hoe uw applicatie werkt. Identificeer alle bronnen die uw applicatie laadt, inclusief scripts, stylesheets, afbeeldingen, lettertypen en eventuele externe diensten waarmee het interacteert. Overweeg de architectuur van uw applicatie en hoe gegevens erdoorheen stromen. Het grondig documenteren van het laadgedrag van de bronnen van uw applicatie is essentieel.

Voorbeeld: Een wereldwijd e-commerceplatform kan scripts laden van zijn eigen domein (bijv. www.example.com), content delivery networks (CDN's) zoals Cloudflare of Akamai, en mogelijk diensten van derden voor analyse of betalingsverwerking. Het plan moet rekening houden met al deze bronnen, zelfs die afkomstig zijn uit verschillende landen of regio's.

2. Beginnen met een restrictief beleid (standaard 'none')

De beste praktijk is om te beginnen met een zeer restrictief beleid en dit geleidelijk te versoepelen als dat nodig is. Begin met default-src 'none'; script-src 'self'; style-src 'self'; img-src 'self';. Dit beleid blokkeert alles standaard en staat alleen toe dat scripts, stijlen en afbeeldingen van dezelfde origin worden geladen. Dit biedt onmiddellijk een sterke basisbescherming.

Voorbeeld:

            Content-Security-Policy: default-src 'none'; script-src 'self'; style-src 'self'; img-src 'self';
            

              
                Copy
              
            
          

3. Externe bronnen identificeren

Identificeer vervolgens alle externe bronnen die uw applicatie gebruikt. Dit omvat CDN's, API's van derden en alle andere domeinen van waaruit uw applicatie assets laadt. Bekijk uw HTML-broncode en netwerkverkeer om alle externe afhankelijkheden te ontdekken.

Voorbeeld: Uw applicatie kan Google Fonts, een JavaScript-bibliotheek gehost op een CDN, en een API van een betalingsgateway gebruiken. Documenteer deze externe bronnen samen met de specifieke protocollen en poorten die worden gebruikt.

4. Het beleid stapsgewijs versoepelen

Voeg voor elke externe bron de juiste richtlijn en bron toe aan uw CSP. Als u bijvoorbeeld een CDN gebruikt, sta die CDN dan toe in uw script-src en/of style-src richtlijnen. Wees zo specifiek mogelijk. Vermijd het gebruik van wildcards, tenzij noodzakelijk. Test uw applicatie grondig na elke wijziging om ervoor te zorgen dat deze correct blijft functioneren en dat de CSP effectief kwaadaardige bronnen blokkeert.

Voorbeeld: Als uw applicatie Google Fonts gebruikt, kunt u font-src https://fonts.gstatic.com; en style-src https://fonts.googleapis.com; aan uw CSP toevoegen. Als u een CDN gebruikt, zoals cdn.example.com, voeg dan script-src cdn.example.com; style-src cdn.example.com; toe.

5. Implementeren en testen

Zodra u uw CSP heeft vastgesteld, implementeert u deze in uw productieomgeving. Test het grondig in verschillende browsers en op verschillende apparaten. Gebruik browser-ontwikkelaarstools en security-testtools om eventuele overtredingen te identificeren. Controleer en update uw CSP regelmatig naarmate uw applicatie evolueert.

6. Monitoren op overtredingen

Implementeer een mechanisme om CSP-overtredingen te monitoren. Wanneer een browser een bron blokkeert vanwege een CSP-overtreding, stuurt het een rapport dat u kunt analyseren. U kunt deze rapportage configureren met de report-uri of report-to richtlijnen.

report-uri: Deze richtlijn specificeert een URL waarnaar de browser rapporten moet sturen wanneer een CSP-overtreding optreedt. Deze richtlijn is nu verouderd ten gunste van report-to.

report-to: Deze richtlijn specificeert een lijst van rapportage-eindpunten waarnaar de browser rapporten moet sturen. Dit biedt meer flexibiliteit bij het afhandelen van rapporten en is de moderne aanbevolen aanpak.

Voorbeeld (report-to):

            Content-Security-Policy: default-src 'self'; script-src 'self' https://example.com; report-to csp-reports;

<?php
  $nonce = bin2hex(random_bytes(16)); // Genereer een willekeurige nonce
  header("Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-{$nonce}'; style-src 'self' 'nonce-{$nonce}';");
?>
<script nonce="">
  // Uw inline JavaScript-code
</script>

            

              
                Copy
              
            
          

2. Strict-Dynamic

De 'strict-dynamic' bronwaarde is een meer geavanceerde aanpak. Het staat scripts toe om andere scripts dynamisch te laden, zolang het oorspronkelijke script dat de andere scripts laadt, is toegestaan. Dit kan nuttig zijn voor frameworks en bibliotheken die scripts dynamisch laden. Gebruik dit voorzichtig en alleen als u de implicaties volledig begrijpt.

Hoe het werkt: Wanneer 'strict-dynamic' wordt gebruikt met script-src, vertrouwt de browser scripts die via een vertrouwd script worden geladen. Alle scripts die dynamisch door een vertrouwd script worden toegevoegd, worden ook toegestaan. Het initiële vertrouwde script moet via een ander mechanisme worden geladen, zoals een nonce of hash.

Voorbeeld:

            Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-{{ nonce }}' 'strict-dynamic';
            

              
                Copy
              
            
          

In dit voorbeeld wordt alleen het script met de nonce in eerste instantie vertrouwd. Echter, alle scripts die dit script dynamisch laadt, worden ook vertrouwd.

3. Trusted Types

Trusted Types is een browserfunctie waarmee u DOM-gebaseerde XSS-aanvallen kunt voorkomen door een strikte API af te dwingen voor het creëren en verwerken van potentieel gevaarlijke gegevens. Het vervangt de mogelijkheid om rechtstreeks HTML uit strings te creëren. Het vereist dat u onveilige strings transformeert naar 'vertrouwde' objecten met behulp van 'sanitizers'. Dit beschermt tegen DOM-gebaseerde XSS-kwetsbaarheden in frameworks en bibliotheken.

Hoe Trusted Types werkt:

1. Definieer een beleid.
2. Registreer beleid voor specifieke acties (bijv. `innerHTML`).
3. Gebruik een sanitizer om gegevens te saneren voordat u ze toewijst aan een DOM-eigenschap.

Voorbeeld (Conceptueel):

            // Creëer een TrustedType-beleid
const policy = trustedTypes.createPolicy('myPolicy', {
    createHTML: (string) => { //Sanitizer. Geef een trustedHTML-object terug.
        // Saniteer de HTML-string voordat u een vertrouwd type teruggeeft
        return string;
    }
});

// Gebruik het beleid om de innerHTML in te stellen
document.body.innerHTML = policy.createHTML("<img src='x' onerror='alert(1)'>");

            

              
                Copy
              
            
          

Momenteel is de browserondersteuning voor Trusted Types relatief beperkt, maar het is een effectieve defensieve maatregel tegen DOM-gebaseerde XSS wanneer het correct wordt gebruikt. Het implementeren van trusted types kan het aanvalsoppervlak aanzienlijk verkleinen.

4. Overtredingen rapporteren (report-to / report-uri)

Het opzetten van een goede rapportage van overtredingen is essentieel voor het monitoren en onderhouden van uw CSP. Gebruik report-to (voorkeur) of report-uri om overtredingsrapporten te sturen naar een eindpunt dat u beheert. Deze rapporten bieden waardevolle inzichten in mogelijke XSS-aanvallen en misconfiguraties.

Hoe rapportage te gebruiken:

1. Stel de report-to of report-uri richtlijn in.
   • report-to: is de voorkeursaanpak. Specificeer het eindpunt waar overtredingsrapporten naartoe worden gestuurd.
   • report-uri: is een verouderde methode, het specificeert de URL van het rapportage-eindpunt.
2. Stel de Content-Security-Policy-Report-Only HTTP-header in (of de equivalente meta-tag): Gebruik deze header in eerste instantie om overtredingen te monitoren zonder bronnen te blokkeren. Hiermee kunt u problemen identificeren en oplossen voordat u de CSP in uw productieomgeving afdwingt.
3. Creëer een rapportage-eindpunt. U kunt een eenvoudige server-side applicatie bouwen (bijv. met Node.js, Python of PHP) om de rapporten te ontvangen en te verwerken. Of gebruik een dienst van derden voor monitoring.
4. Analyseer de rapporten. Onderzoek de details van de overtreding, inclusief de geblokkeerde URI, de geschonden richtlijn en de bron van het script. Deze informatie kan u helpen XSS-kwetsbaarheden en misconfiguraties te identificeren en op te lossen.

5. CSP in Meta Tags (Report-Only en Afdwingen)

CSP kan op twee manieren worden geleverd: als een HTTP-header of als een <meta>-tag in uw HTML.

• HTTP-header: De aanbevolen methode, het leveren van de CSP als een HTTP-header, is over het algemeen veiliger omdat deze wordt toegepast voordat de pagina-inhoud wordt geparsed. Dit voorkomt mogelijke omzeilingen die mogelijk zijn met <meta>-tags.
• <meta>-tag: U kunt de CSP ook opnemen met een <meta>-tag in de <head>-sectie van uw HTML. Het http-equiv-attribuut specificeert het type beleid. Bijvoorbeeld: <meta http-equiv="Content-Security-Policy" content="...">.

De <meta>-tag biedt het `Content-Security-Policy-Report-Only`-attribuut om de CSP in alleen-rapportagemodus te implementeren. Hiermee kunt u overtredingen monitoren zonder iets te blokkeren.

Alleen-rapportagemodus (aanbevolen voor initiële implementatie):

            <meta http-equiv="Content-Security-Policy-Report-Only" content="default-src 'self'; script-src 'self' https://example.com; report-to csp-reports;">
            

              
                Copy
              
            
          

Deze modus stelt u in staat om overtredingsrapporten te verzamelen zonder de functionaliteit van uw website te beïnvloeden. U kunt het gebruiken om uw CSP te testen en eventuele problemen te identificeren voordat u het in productie afdwingt. Bekijk overtredingsrapporten, pas uw CSP indien nodig aan en schakel vervolgens over naar de `Content-Security-Policy`-header voor handhaving.

6. CSP met Web Application Firewalls (WAF's)

Een Web Application Firewall (WAF) biedt een extra beveiligingslaag voor uw webapplicaties. WAF's kunnen worden gebruikt om kwaadaardig verkeer, inclusief XSS-aanvallen, te detecteren en te blokkeren. U kunt uw WAF configureren om samen te werken met uw CSP om uw beveiligingspositie te versterken.

Hoe WAF's en CSP kunnen samenwerken:

1. WAF als eerste verdedigingslinie: Een WAF kan kwaadaardige verzoeken filteren voordat ze uw applicatie bereiken. Het kan bekende XSS-aanvalspatronen identificeren en blokkeren.
2. CSP als tweede verdedigingslinie: CSP biedt een extra beschermingslaag door te beperken welke bronnen een pagina kan laden, zelfs als kwaadaardige inhoud erin slaagt de WAF te omzeilen.
3. Integratie met CSP-rapporten: Sommige WAF's kunnen integreren met CSP-overtredingsrapporten. Ze kunnen u waarschuwen voor mogelijke aanvallen en gedetailleerde informatie geven over de aard van de aanval.

Best Practices en Praktische Inzichten

• Begin restrictief: Begin met een zeer restrictieve CSP (bijv. default-src 'none';). Dit minimaliseert het aanvalsoppervlak.
• Test grondig: Test uw CSP rigoureus in alle grote browsers en op verschillende apparaten voordat u het in productie implementeert. Gebruik zowel handmatige tests als geautomatiseerde testtools.
• Monitor overtredingen: Monitor en analyseer regelmatig CSP-overtredingsrapporten om beveiligingsproblemen te identificeren en aan te pakken. Stel geautomatiseerde waarschuwingen in om op de hoogte te worden gesteld van mogelijke aanvallen.
• Houd het up-to-date: Naarmate uw applicatie evolueert, update uw CSP om wijzigingen in uw laadpatronen van bronnen weer te geven. Blijf op de hoogte van de beste beveiligingspraktijken.
• Vermijd 'unsafe-inline' en 'unsafe-eval': Deze waarden verzwakken uw CSP aanzienlijk en moeten worden vermeden. Gebruik altijd nonces of hashes voor inline scripts/stijlen.
• Gebruik aanvankelijk de alleen-rapportagemodus: Wanneer u een nieuwe CSP implementeert of belangrijke wijzigingen aanbrengt, gebruik dan de alleen-rapportagemodus om het beleid te testen en potentiële problemen te identificeren voordat u het afdwingt.
• Overweeg diensten van derden: Gebruik diensten (zoals Sentry, Report URI of Cloudflare) om te helpen met CSP-rapportage en -analyse. Dit kan het proces vereenvoudigen en waardevolle inzichten bieden.
• Onderwijs uw team: Zorg ervoor dat uw ontwikkelingsteam het belang van CSP begrijpt en veilige codeerpraktijken volgt om het risico op XSS-kwetsbaarheden te minimaliseren. Train uw ontwikkelaars in veilige codeerpraktijken en XSS-preventietechnieken.
• Implementeer security audits: Voer regelmatig security audits uit om kwetsbaarheden te identificeren en de effectiviteit van uw CSP te beoordelen.
• Gebruik automatisering: Automatiseer het proces van het genereren van nonces en hashes. Integreer CSP-testen in uw CI/CD-pijplijn.

Wereldwijde overwegingen

Houd bij het implementeren van CSP voor een wereldwijd publiek rekening met het volgende:

• Prestaties: Minimaliseer de impact van CSP op de prestaties van de website. Gebruik efficiënte technieken voor het laden van bronnen en optimaliseer uw CSP om onnodige beperkingen te vermijden. Kies geografisch verspreide CDN's voor assets.
• Lokalisatie: Zorg ervoor dat uw CSP niet interfereert met gelokaliseerde inhoud of bronnen. Als u bijvoorbeeld een CDN gebruikt voor vertaalde inhoud, zorg er dan voor dat u die CDN opneemt in uw CSP.
• Toegankelijkheid: Test uw CSP om ervoor te zorgen dat het de toegankelijkheid voor gebruikers met een handicap niet negatief beïnvloedt.
• Regionale regelgeving: Wees u bewust van de regelgeving inzake gegevensprivacy in verschillende regio's. De Algemene Verordening Gegevensbescherming (AVG) in de Europese Unie en de California Consumer Privacy Act (CCPA) in de Verenigde Staten kunnen bijvoorbeeld van invloed zijn op hoe u gebruikersgegevens verzamelt en verwerkt, wat uw CSP-configuratie kan beïnvloeden.
• Mobiele gebruikers: Test uw CSP op mobiele apparaten en browsers om ervoor te zorgen dat het adequate bescherming biedt en de mobiele gebruikerservaring niet belemmert. Mobiele apparaten en browsers gaan vaak iets anders om met CSP, dus grondig testen is cruciaal.

Conclusie

Het implementeren van een geavanceerde Content Security Policy is een cruciale stap in het beschermen van uw webapplicaties tegen XSS-aanvallen. Door te beginnen met een restrictief beleid, richtlijnen zorgvuldig te configureren en technieken zoals nonces, hashes en rapportage te gebruiken, kunt u uw aanvalsoppervlak aanzienlijk verkleinen en de veiligheid van uw wereldwijde web-aanwezigheid verbeteren. Vergeet niet om uw CSP grondig te testen, te monitoren op overtredingen en uw beleid continu bij te werken naarmate uw applicatie evolueert. Door deze best practices toe te passen, kunt u uw gebruikers beschermen en het vertrouwen in uw merk behouden, ongeacht hun locatie of achtergrond.